diff --git a/convex/skillStatEvents.ts b/convex/skillStatEvents.ts
index 03d6722..03f2ddc 100644
--- a/convex/skillStatEvents.ts
+++ b/convex/skillStatEvents.ts
@@ -290,6 +290,15 @@ const MAX_SKILLS_PER_RUN = 500
 /**
  * Fetch a batch of events after the given cursor (by _creationTime).
  * Returns events sorted by _creationTime ascending.
+ *
+ * Uses .gte() (greater than or equal) instead of .gt() to ensure we don't skip
+ * events that share the same _creationTime as the cursor. Since events can be
+ * created within the same millisecond, using .gt() would lose events at the
+ * boundary when batches are split by skill limits.
+ *
+ * To avoid reprocessing: callers must use cursorCreationTime from a previous
+ * complete run (exhausted = true), or must be prepared to re-aggregate events
+ * with the same skillId (which is safe since aggregation is idempotent).
  */
 export const getUnprocessedEventBatch = internalQuery({
   args: {
@@ -300,11 +309,13 @@ export const getUnprocessedEventBatch = internalQuery({
     const limit = args.limit ?? EVENT_BATCH_SIZE
     const cursor = args.cursorCreationTime
 
-    // Query events after the cursor using the built-in creation time index
+    // Query events at or after the cursor using the built-in creation time index.
+    // We use .gte() (>=) instead of .gt() (>) to handle the case where multiple
+    // events share the same _creationTime but are split across batch boundaries.
     const events = await ctx.db
       .query('skillStatEvents')
       .withIndex('by_creation_time', (q) =>
-        cursor !== undefined ? q.gt('_creationTime', cursor) : q,
+        cursor !== undefined ? q.gte('_creationTime', cursor) : q,
       )
       .take(limit)
     return events

Analysis

Cursor-based pagination loses events with duplicate _creationTime timestamps

What fails: The processSkillStatEventsAction function in convex/skillStatEvents.ts can permanently lose unprocessed skill stat events when multiple events share the same _creationTime value and batch processing is interrupted by the skill limit.

How to reproduce:

1. Insert stat events where multiple events have the same _creationTime timestamp (possible in Convex since events can be created within the same millisecond)
2. Ensure enough events exist at that timestamp to span across batch boundaries
3. Configure MAX_SKILLS_PER_RUN small enough that processing stops mid-batch (e.g., 2-3 unique skills)
4. Run the action - it processes the first batch and hits the skill limit
5. The cursor is saved as the maximum _creationTime seen
6. Run the action again - the query uses .gt() (strictly greater than) to fetch the next batch
7. Events with _creationTime equal to the saved cursor are permanently skipped

Result: Events that were never processed are lost, resulting in permanently missing stat updates for those events.

Expected: All events should be processed exactly once, even when they share the same _creationTime timestamp.

Root cause: The getUnprocessedEventBatch query at line 307 uses .gt('_creationTime', cursor) which performs a strictly greater-than comparison. When events are batched and the batch boundary falls in the middle of a group of events with the same _creationTime, subsequent queries will skip those boundary events.

Fix applied: Changed the query operator from .gt() to .gte() (greater than or equal) in the getUnprocessedEventBatch query function. This ensures events at the cursor timestamp are included in subsequent batches. The aggregation logic is idempotent (processing the same skill's events twice produces the same result), so minor reprocessing of boundary events is safe.

See: Convex index documentation on comparison operators - .gte() performs greater-than-or-equal comparison as opposed to .gt()'s strictly greater-than behavior.